Carnegie-Mellon  University 

Software  Engineering  Institute 


Technical  Report 

SEI-86-TM-3 
ESD-TR-86-206 
March  1986 


Understanding  the  Implications  of 
Selling  Rights  in  Software  to  the 
Defense  Department:  A  Journey 
Through  the  Regulatory  Maze 


by 

Pamela  Samuelson 

Principal  Investigator,  Software  Licensing  Project 
Software  Engineering  Institute 
Carnegie-Mellon  University 
Pittsburgh,  PA  15213 


Approved  for  Public  Release.  Distribution  Unlimited. 


This  work  was  sponsored  by  the  Department  of  Defense. 

The  views  and  conclusions  in  this  document  are  those  of  the  author  and  should  not  be  interpreted  as  representing  official  policies, 
either  expressed  or  implied,  of  the  Software  Engineering  Institute,  Carnegie* Mellon  University,  the  Department  of  Defense,  or 
the  U.S.  Government, 


Copyright  (c)  1986.  Pamela  Samueison. 


Technical  Report 
CMU/SEI-86-TM-3 
ESD-TR-86-206 
March  1986 


This  technical  report  was  prepared  for  the 


SEi  Joint  Program  Office 
ESD/XRS1 

Hanscom  AFB,  MA  01731 


The  ideas  and  findings  in  this  report  should  not  be  construed  as  an  official  DoD  position,  it 
is  published  in  the  interest  of  scientific  and  technical  information  exchange. 


Review  and  Approval 


This  report  has  been  reviewed  and  is  approved  for  publication. 


FOR  THE  COMMANDER 


Karl  H.  Shingler 

SEI  Joint  Program  Office 


This  document  Is  available  through  the  Defense  Technical  Information  Center.  DTIC  provides  access  to  and  transfer  of  scientific 
and  technical  information  for  DoD  personnel,  DoD  contractors  and  potential  contractors,  and  other  U.S.  Government  agency  personnel 
and  their  contractors.  To  obtain  a  copy,  please  contact  DTIC  directly:  Defense  Technical  Information  Center,  Attn:  FDRA,  Cameron 
Station,  Alexandria,  VA  22304-6145 

Copies  of  this  document  are  also  available  through  the  National  Technical  Information  Services.  For  Information  on  ordering,  please 
contact  NTIS  directly:  National  Technical  Information  Servioes,  U.S.  Department  of  Commerce,  Springfield,  VA  22161 . 


Understanding  the  Implications 
of  Selling  Rights 

In  Software  to  the  Defense  Department: 

A  Journey  Through  the  Regulatory  Maze 


Pamela  Samuelson 


Abstract.  This  article  of  the  Software  Licensing  Project  of  the  SEI  examines  problems  related  to 
DoD  procurement  policy  as  reflected  in  the  DoD  acquisition  regulations  (DoD  FAR  SUPP).  This 
article  discusses  ambiguities  and  inconsistencies  found  in  the  acquisition  regulations,  and  ways  in 
which  these  problem  areas  might  result  in  unexpected  disadvantages  to  both  the  government  and 
industry.  Issues  related  to  funding  of  software  development,  treatment  of  technical  data  and 
documentation,  the  concept  of  unlimited  rights,  the  making  of  derivative  works  and  other  modifica¬ 
tions  of  software,  and  the  interface  between  DoD  acquisition  policy  and  intellectual  property  laws 
(such  as  copyright  and  trade  secret  law)  are  discussed.  The  article  serves  to  catalogue  potential 
problems  that  might  arise  under  the  DoD  acquisition  regulations. 

The  Defense  Department  has  in  recent  years  been  sponsoring  the  development  of  a  large  num¬ 
ber  of  very  sophisticated  software  systems.  Many  companies  are  interested  in  exploring  the 
possibility  of  participating  in  one  or  more  DoD-sponsored  software  development  projects.  Small 
firms,  in  particular,  may  be  drawn  to  DoD  as  a  source  of  funding  for  large  scale  projects,  perhaps 
hoping  that  the  software  developed  for  the  military  will  also  (at  least  with  some  modifications) 
have  a  significant  commercial  market.  The  company  may  think  it  worthwhile  to  take  DoD  funding 
because  that  will  pick  up  the  initial  development  costs,  and  then  profits  can  be  made  on  commer¬ 
cial  sales. 

One  of  the  perceived  drawbacks  to  making  such  a  deal  with  the  Defense  Department  is  the  "data 
rights"  policy  the  Department  has  adopted  to  allocate  and  administer  what  rights  the  government 
and  its  contractors  will  have  as  to  software  acquired  by  the  government.  The  DoD  data  rights 
policy  is  often  decried  as  "confiscatory"  by  industry  people,  although  just  how  and  to  what  extent 
it  is  "confiscatory"  is  not  well  understood.  Given  the  length  and  complexity  of  the  standard  data 
rights  clause  that  DoD  inserts  in  virtually  all  of  its  software  acquisition  contracts,  it  is  not  surprising 
that  many  industry  people  do  not  know  the  full  implications  of  the  clause.  This  article  will  set  forth 
as  simply  and  clearly  as  the  author's  capabilities  permit  what  rights  contractors  are  likely  to  have  • 
and  not  have  -  when  selling  rights  in  software  to  the  Defense  Department.  The  article  will  also 
assess  the  potential  risks  of  negotiating  non-standard  contract  terms  with  special  contractual 
language.  Not  all  such  special  language  may  be  enforceable  for  reasons  set  forth  at  some  length 
below. 


Limits  on  Flexibility 

There  are  many  places  one  can  begin  this  examination  of  the  standard  data  rights  policy.  This 
article  will  begin  with  pointing  out  how  little  flexibility  DoD's  own  contracting  personnel  seem  to 
have  under  the  current  procurement  regime.  The  regulations  say  that  the  standard  data  rights 


clause  is  to  be  incorporated  into  every  software  acquisition  contract  into  which  the  Defense 
Department  enters,  unless  a  formal  "deviation"  is  granted  owing  to  special  circumstances.  The 
mandatory  nature  of  the  standard  data  rights  clause  is  an  important  limit  on  the  ability  of  contract¬ 
ing  personnel  to  reach  agreements  that  contravene  clear  mandates  of  the  standard  clause. 

This  is  not  to  say  that  the  clause  is  completely  inflexible.  One  can,  for  example,  negotiate  a 
special  set  of  terms  to  control  the  government’s  use  of  privately  developed  software  so  long  as 
the  government  still  has  the  four  minimum  rights  prescribed  in  the  standard  clause  .  But  an 
agreement  purporting  to  take  away  from  the  government  one  of  the  four  standard  minimum  rights 
would  be  of  questionable  validity  absent  authorization  for  a  deviation.  Similarly,  a  specially 
negotiated  arrangement  which  would  give  the  government  less  than  "unlimited  rights"  in  software 
funded  in  whole  or  in  part  with  federal  money  would  be  of  questionable  validity.  If  the  standard 
data  rights  clause  is  included  in  a  government  contract  (or,  for  that  matter,  a  subcontract),  the 
mandatory  clause  seems  likely  to  prevail  over  any  contradicting  specially  negotiated  provisions  if 
a  dispute  between  the  parties  over  rights  arises  in  the  future. 

Conflicts  Between  The  Standard  Clause  and  Special  Clauses 

The  policy  reasons  that  support  enforcement  of  the  standard  data  rights  clause  over  a  specially 
negotiated  clause  are  straightforward:  The  Defense  Department  buys  a  tremendous  volume  of 
software  (and  other  items).  It  needs  a  way  of  predicting  with  some  certainty  what  minimum  rights 
it  will  have  in  this  property.  The  standard  data  rights  clause  is  the  vehicle  for  obtaining  such 
assurances.  It  is  required  to  be  used  by  agency  regulations;  it  is  itself  a  regulation.  (It  Is  well  to 
remember  that  agency  regulations  have  the  force  and  effect  of  law.)  The  standard  clause  sets 
forth  the  basic  transactional  rules  that  the  government  has  decided  are  necessary  to  protect  its 
interests.  Because  there  is  a  way  within  the  regulations  to  alter  the  standard  data  rights  policy, 
namely  the  formal  deviation,  specially  negotiated  terms  that  contradict  the  standard  clause  might 
well  be  found  ineffective  when  the  deviation  process  was  not  used  to  obtain  the  right  to  an 
exception.  This  policy  argument  would  seem  to  apply  equally  to  subcontracting  situations  as  to 
prime  contractor  situations. 

Nevertheless,  there  may  be  some  instances  in  which  a  software  company  and  DoD  contracting 
personnel  have  gone  ahead  and  entered  into  special  arrangements  in  which  the  standard  data 
rights  clause  may  be  incorporated  by  reference  and  in  which  separate  clauses  contradicting  part 
of  this  standard  clause  will  also  appear.  The  government  contract  officer  and  the  industry  repre¬ 
sentative  may  have  between  themselves  reached  an  understanding  that  the  specially  negotiated 
language  will  govern.  In  many  and  perhaps  most  instances,  the  deal  may  go  smoothly  and  no 
disputes  about  rights  will  arise.  In  the  event  of  a  dispute,  the  Defense  Department  might  well  take 
the  position  that  the  standard  data  rights  clause  prevails  over  the  specially  negotiated  terms  for 
the  policy  reasons  discussed  above.  It  may  also  argue  the  contract  officer  (or  the  prime  contrac¬ 
tor  in  the  subcontract  situation)  had  no  authority  to  make  special  arrangements  without  getting  a 
deviation.  The  inequity  of  subjecting  a  firm  to  vastly  different  terms  than  it  had  agreed  to  would 
probably  give  way  to  the  larger  policy  underlying  the  procurement  regulations.  This  is  a  potential 
risk  for  firms  that  sell  rights  in  software  to  the  government. 
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Different  Treatment  for  Software  and  Its  Associated  Documentation 

There  are  many  features  of  the  DoD  standard  data  rights  clause  that  differ  from  standard  com¬ 
mercial  practices.  One  important  example  of  this  is  in  the  different  treatment  accorded  to 
machine-readable  code  and  to  software  documentation.  DoD  defines  "software"  in  such  a  way  as 
to  encompass  only  machine-readable  code;  software  documentation  is  considered  to  be 
"technical  data." 

If  both  the  machine-readable  code  and  documentation  have  been  developed  (at  least  in  part)  at 
public  expense,  the  separate  classification  of  machine-readable  code  and  documentation  will 
matter  very  little  because  the  government  will  claim  the  same  "unlimited  rights"  in  both.  If  they 
have  instead  been  developed  wholly  at  private  expense,  however,  the  machine-readable  code 
will  be  subject  to  a  tighter  set  of  restrictions  than  the  documentation  (except  if  the  software  is  an 
off-the-shelf  commercial  product). 

Privately  developed  machine-readable  code  purchased  by  DoD  must  be  acquired  with  four  stan¬ 
dard  minimum  "restricted  rights"  in  the  government.  They  are:  (1)  the  right  to  use  it  in  the 
computer  or  facility  for  which  it  was  obtained,  (2)  the  right  to  use  it  in  a  backup  computer  if  the 
intended  use  computer  is  inoperable,  (3)  the  right  to  make  a  backup  copy  of  it,  and  (4)  the  right  to 
modify  it.  Privately  developed  software  documentation  will  typically  be  acquired  with  "limited 
rights"  in  the  government  which  means  that  the  government  will  have  the  rights  to  use,  copy,  and 
disclose  it  throughout  the  government,  and  in  emergency  repair  situations,  to  have  these  same 
acts  performed  by  outsiders.  (The  exceptions  to  this  general  rule,  for  commercial  software  and 
for  manuals  or  instructional  material  needed  for  installation  and  training  are  discussed  in  a  later 
section.) 

It  should  be  readily  apparent  that  DoD’s  discrepant  treatment  of  privately  developed  machine- 
readable  code  and  its  documentation  is  at  odds  with  commercial  practice,  which  tends  either  to 
treat  software  and  documentation  the  same,  or  to  treat  documentation  more  restrictively  than 
executable  code.  This  is  a  feature  of  DoD’s  policy  that  warrants  careful  consideration  by  software 
firms  supplying  software  and  documentation  to  the  government. 

Public  vs.  Private  Funding  of  Software 

Undoubtedly  the  most  important  distinction  in  the  DoD  standard  data  rights  clause  is  that  between 
"publicly  funded  software"  and  "privately  developed  software."  The  government  will  claim 
"unlimited  rights"  in  any  software  and  documentation  developed  with  public  funding;  it  will  treat  as 
"proprietary"  any  software  developed  at  private  expense. 

The  DoD  takes  an  "all  or  nothing"  approach  in  these  situations.  That  is,  no  matter  how  much  of  a 
private  firm’s  own  money  has  gone  Into  the  development  of  a  piece  of  software,  and  no  matter 
how  valuable  that  software  or  its  prototype  may  be,  if  even  one  dollar  of  DoD  money  has  gone 
into  the  software’s  development  fund,  the  government  will  claim  unlimited  rights  In  that  software 
and  documentation.  This  policy  is  sometimes  viewed  by  industry  as  particularly  inequitable  when 
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the  DoD  money  has  paid  only  for  slight  modifications  to  the  code  which  were  necessary  to  make 
the  software  suitable  for  government  purposes.  Industry  has  been  trying  for  many  years  to  alter 
this  policy. 

Indeed,  recent  legislation  seems  to  call  for  the  establishment  of  some  form  of  middle  ground 
alternative  for  mixed  funding  situations.  The  newly  proposed  Federal  Acquisition  Regulations 
(FAR)  would,  for  example,  permit  the  government  and  a  contractor  to  make  arrangements  for  the 
government  to  get  less  than  unlimited  rights  when  both  supply  funds  for  the  development  of 
software.  The  new  FAR  would  also  permit  firms  to  retain  "privately  developed"  status  for  software 
that  has  been  slightly  modified  by  a  contractor  to  make  it  suitable  for  government  use.  This  is 
not,  however,  the  Defense  Department’s  policy,  as  reflected  in  the  current  DoD  FAR  Supplement 
and  under  the  proposed  amendments  to  it. 

Unlimited  Rights:  What  Does  That  Mean  Vls-a-VIs  Ownership? 

As  indicated  above,  the  standard  data  rights  clause  provides  that  if  DoD  provides  funding  for  any 
part  of  the  development  costs  for  software,  it  will  claim  "unlimited  rights"  in  the  software  and  its 
associated  documentation.  There  seems  to  be  some  confusion  within  DoD,  as  well  as  in  the 
industry,  about  what  the  meaning  of  unlimited  rights  is  vis-a-vis  an  ownership  interest.  Many 
people  seem  to  think  that  unlimited  rights  is  equivalent  to  an  ownership  interest. 

It  appears,  from  a  close  examination  of  the  standard  data  rights  clause,  that  this  assumption  is 
not  accurate.  The  definition  of  unlimited  rights  under  the  DoD  clause  makes  no  mention  of  an 
ownership  interest.  "Unlimited  rights"  is  defined  in  the  standard  data  rights  clause  to  mean  only 
the  rights  to  use,  duplicate  and  disclose  software  and  its  documentation  in  any  manner  and  for 
any  purpose  and  to  have  or  permit  others  to  do  the  same.  While  this  is  surely  a  very  broad 
license,  it  appears  that  it  is  not  an  ownership  interest.  In  intellectual  property  law,  ownership 
rights  are  defined  in  terms  of  rights  to  exclude  other  people  from  doing  one  or  more  things  with 
the  property;  the  definition  of  unlimited  rights  confers  no  rights  to  exclude  on  the  government. 
Furthermore,  a  close  reading  of  the  DoD  procurement  policy  regulations  reveals  that  when  DoD 
wants  to  try  to  take  an  ownership  interest  in  software,  it  should  use  the  "special  works"  clause 
instead  of  the  standard  data  rights  clause. 

The  Effect  of  Use  of  a  Special  Works  Clause 

The  DoD  special  works  clause  purports  to  give  to  the  government  an  ownership  right  and  a  direct 
copyright  interest  in  software  or  other  work  prepared  under  a  government  contract  in  which  this 
clause  is  used.  The  clause  claims  this  direct  copyright  interest  by  claiming  that  the  work  prepared 
by  the  contractor  under  the  clause  is  a  "work  made  for  hire"  under  the  copyright  law.  Unfor¬ 
tunately,  the  DoD  special  works  clause,  insofar  as  it  purports  to  give  the  government  a  direct 
copyright  interest  in  software,  may  be  ineffective  for  this  purpose  because  it  conflicts  with  the 
copyright  law  in  two  respects:  (1)  software  is  not  a  category  of  specially  commissioned  work  that 
qualifies  for  the  "work  made  for  hire"  rules,  and  (2)  the  copyright  law  specifically  prohibits  the 
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government  from  directly  owning  copyrights  (see  17  U.S.C.  Section  105).  The  effect  of  putting 
the  DoD  special  worths  clause  in  a  software  development  contract  would  seem  to  be  to  put  the 
software  and  associated  documentation  in  the  public  domain.  Use  of  the  special  works  clause 
seems  to  nullify  the  contractors  right  to  claim  ownership  in  the  software. 

How  Broad  Is  The  Unlimited  Rights  License? 

How  broad  the  government’s  rights  are  when  it  has  unlimited  rights  in  software  might  seem  a 
tritely  simple  question,  but  it’s  not.  Some  procurement  personnel  tend  to  interpret  the  term  as  if  it 
was  tautologically  defined  (i.e.,  that  "unlimited  rights"  means  "unlimited"  rights.)  But  the  DoD’s 
own  definition  of  the  term  is  limited  to  three  basic  rights:  the  rights  to  use,  duplicate,  and  disclose 
the  software.  The  most  glaring  omission  from  the  definition  is  that  relating  to  rights  to  prepare 
derivative  works.  Derivative  works  are  defined  broadly  by  the  copyright  law.  There  is  as  yet  little 
case  law  to  provide  guidance  as  to  the  scope  of  this  concept  vis-a-vis  software  but  it  would  seem 
to  include  all  modifications,  enhancements, translations  into  other  programming  languages,  and 
the  development  of  additional  programs  using  parts  of  the  original  code  (i.e.,  reusability  of 
software.)  Although  DoD  might  argue  that  a  derivative  works  right  is  implicitly  included  in  the 
DoD  rights,  it  is  at  least  conceivable  that  a  court  might  find  that  the  DoD  does  not  obtain  the  right 
to  make  derivative  works  of  copyrighted  material  when  it  has  unlimited  rights.  DoD’s  argument 
for  implicit  inclusion  is  weakened  because  the  newly  proposed  FAR  does  define  unlimited  rights 
to  include  a  right  to  make  derivatives. 

If  firms  that  have  developed  software  with  government  funds  retain  the  right  to  control  the 
government’s  preparation  of  derivative  software,  that  would  certainly  be  an  important  limitation  on 
the  government’s  rights.  It  is  simply  unclear  whether  this  is  so. 

Contractor-Prepared  Derivatives  of  Unlimited  Rights  Software 

As  important  a  question  as  may  be  the  government’s  right  to  prepare  derivative  software,  an  even 
more  important  question  from  industry’s  perspective  may  be  whether  the  government  will  have 
any  rights-  or  perhaps  even  unlimited  rights  --  in  any  contractor-prepared  derivative  software 
intended  for  the  commercial  market.  If  DoD  funds  have  paid  for  development  of  the  original 
software  and  if  some  part  of  the  original  software  is  traceable  in  the  derivative  software,  some 
DoD  personnel  might  argue  that  the  government  will  (or  should)  have  unlimited  rights  in  the 
derivative  software  as  well  --  despite  the  fact  that  delivery  of  derivative  software  may  never  have 
been  called  for  under  any  contract. 

The  problem  of  what  it  might  mean  for  the  government  to  have  unlimited  rights  in  non¬ 
deliverables  is  always  a  thorny  one,  but  in  the  context  of  derivative  software,  it  could  cause 
considerable  concern.  How  a  court  would  resolve  a  dispute  of  this  sort  is  difficult  to  predict.  It 
might  seem  inequitable  to  the  software  industry  for  the  government  to  claim  broad  rights  in 
derivative  software  whose  delivery  they  never  bargained  for.  However,  DoD  might  very  well  take 
the  position  that  the  government  can  and  should  exercise  rights  to  derivative  software. 
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The  Effect  of  Copyrighting  Software  Developed  at  Public  Expense 

The  making  of  derivative  software  from  software  funded  at  public  expense  can  also  be  a  compli¬ 
cated  problem  if  the  developer  of  the  original  software  has  copyrighted  the  software  (as  the 
standard  data  rights  clause  permits)  and  if  a  different  company  is  selected  to  prepare  the  deriva¬ 
tive  software  for  the  government.  As  was  pointed  out  above,  it  is  not  entirely  clear  that  the 
government  has  the  right  to  authorize  the  making  of  derivatives.  For  the  moment,  let’s  assume  it 
does.  That  still  doesn’t  mean  that  there  are  no  limits  on  the  government’s  ability  to  authorize  the 
creation  of  derivatives.  One  provision  of  the  standard  data  rights  clause  suggests  that  the 
government’s  rights  to  do  various  things  with  copyrighted  software  and  to  authorize  others  to  do 
the  same  is  limited  to  circumstances  in  which  they  are  done  for  governmental  purposes.  The 
regulation  is  somewhat  ambiguous  in  this  respect,  but  it  may  be  that  the  effect  of  a  contractor's 
copyrighting  software  it  has  developed  with  government  funding  will  be  to  narrow  the  scope  of  the 
government’s  rights  in  that  software  from  an  "any  purpose"  license  to  a  "government  purposes” 
license,  that  is,  to  contract  the  scope  of  unlimited  rights. 

This  contraction  of  the  government’s  rights  may  be  particularly  important  as  to  the  creation  of 
derivative  software,  for  it  may  permit  the  original  developer  (insofar  as  it  may  be  a  copyright 
owner)  to  control  distribution  of  derivative  software  prepared  by  a  second  firm  to  anyone  besides 
the  government.  That  is,  the  first  firm  may  not  be  able  to  prevent  a  second  firm  from  preparing  a 
derivative  program  for  the  government,  but  it  may  at  least  be  able  to  prevent  the  second  firm  from 
copyrighting  the  derivative  and  selling  it  widely  to  commercial  customers.  The  government  can¬ 
not  give  to  the  second  firm  a  wider  set  of  rights  than  the  first  firm  has  given  to  the  government. 
And  if  the  second  firm  --  even  with  the  government’s  permission  --  exceeds  the  scope  for  the 
government’s  license,  it  may  be  enjoined  from  infringing  the  first  firm’s  copyright,  and  thus  be 
unable  to  bring  the  derivative  to  market. 

The  Policy  When  Software  Is  Developed  At  Private  Expense 

Having  now  a  clearer  understanding  of  the  risks  and  uncertainties  involved  when  a  firm  accepts 
government  funding  for  software  development,  a  software  firm  may  prefer  to  find  some  Inde¬ 
pendent  source  of  funding  for  the  software  to  avoid  the  problems  just  described.  The  firm  may 
think,  "Well,  at  least  if  it’s  privately  developed,  I’ll  be  able  to  restrict  the  government’s  use  of  it." 
To  an  extent,  this  is  true;  to  an  extent,  it  may  not  be  true.  In  the  event  a  contractor  firm  uses  its 
own  funds  for  software  development  as  a  way  of  ensuring  its  ability  to  restrict  the  government’s 
rights  in  the  software,  the  firm  should  realize  that  it  must  still  follow  a  circuituous  path  through  the 
data  rights  regulations  to  secure  the  restricted  rights  protection  it  may  be  seeking. 

Commercial  Software:  The  Option 

One  of  the  potentially  helpful  provisions  for  industry  as  to  privately  developed  "commercial 
software"  that  it  may  take  some  experience  with  the  clause  to  discern  is  that  the  standard  data 
rights  clause  allows  contractors  to  opt  whether  to  have  their  commercial  software  treated  as 
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"commercial  software"  or  as  "other-than-commercial  software."  (What  qualifies  as  "commercial 
software"  is  not  clear  from  the  regulatory  definition;  it  seems  to  be  interpreted  to  reach  off-the- 
shelf  software  that  has  a  substantial  commercial  distribution.) 

The  primary  advantage  of  having  one’s  software  treated  as  "commercial  software"  is  that  its 
documentation  will  be  subject  to  the  same  "restricted  rights”  as  applies  to  the  machine-readable 
code  instead  of  being  subject  to  the  broader  limited  (i.e.,  government-wide)  rights  that  pertain  to 
other  documentation.  The  primary  disadvantage  of  opting  for  commercial  software  treatment  is 
that  there  is  a  fixed  and  unnegotiable  set  of  terms  that  will  apply  to  the  code  and  the  documen¬ 
tation;  no  further  terms  can  be  negotiated.  Some  firms  with  commercial  software  prefer  to  be 
able  to  negotiate  additional  terms,  and  thus  exercise  the  option  to  have  commercial  software 
treated  as  other-than-commercial-software. 


Other  Than  Commercial  Software:  A  "Booby  Trap" 

The  DoD  standard  data  rights  clause  contemplates  that  when  DoD  acquires  other-than- 
commercial-software  that  has  been  developed  at  private  expense,  a  separate  licensing  agree¬ 
ment  will  be  negotiated  between  the  government  and  the  software  firm  which  will  then  be  made 
part  of  the  government  contract.  The  DoD  must  only  get  the  standard  four  minimum  rights  in  the 
software. 

An  interesting  question  is:  what  happens  if  the  firm  fails  to  negotiate  a  separate  license  agree¬ 
ment  and  have  the  agreement  made  part  of  the  government  contract?  A  cursory  reading  of  the 
standard  data  rights  clause  might  suggest  to  an  industry  person  that  if  no  license  agreement  was 
entered  into  between  the  government  and  the  contractor,  the  government  would  have  no  more 
than  the  four  standard  minimum  rights  in  the  software.  However,  a  closer  reading  of  the  clause 
itself  indicates  that  the  failure  to  negotiate  a  separate  license  or  the  failure  to  have  a  separate 
agreement  made  part  of  the  government  contract  may  instead  mean  that  the  government  will 
have  unlimited  rights  in  the  software  (that  is,  at  least,  in  the  machine-readable  code).  This  may 
strike  software  industry  people  as  unreasonable,  but  it  Is  the  result  a  close  reading  of  the  regula¬ 
tions  seems  to  contemplate  for  those  who  don’t  negotiate  a  separate  agreement  and  have  it 
made  part  of  the  contract.  It  would  certainly  be  prudent  to  negotiate  a  separate  licensing  agree¬ 
ment  and  have  it  made  part  of  the  contract  if  a  firm  wants  to  ensure  that  its  privately  developed 
software  will  be  subject  to  tight  restrictions. 


Other  Technicalities 

Similarly,  the  failure  of  the  contractor  to  put  a  restrictive  notice  on  the  software  or  documentation, 
or  the  failure  of  the  contractor  to  identify  in  his  proposal  a  piece  of  software  as  to  which  he  desires 
to  negotiate  restricted  rights  could  result  in  the  government’s  claiming  unlimited  rights  in  that 
software,  even  if  the  software  was  developed  wholly  with  private  funds.  Further,  even  if  the 
software  and  documentation  was  developed  wholly  at  private  expense,  and  even  if  one  has  been 
careful  to  comply  with  the  technical  requirements  of  the  regulations,  a  software  firm  might  be 
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threatened  with  loss  of  its  limited  (or  restricted)  right  protection  for  software  documentation  to  the 
extent  that  the  documentation  has  been  incorporated  into  a  manual  or  other  instructional  material 
prepared  for  or  required  to  be  delivered  under  the  government  contract  to  assist  with  installation, 
operation,  maintenance,  or  training.  The  government  claims  unlimited  rights  in  all  such  manuals 
and  materials.  Unfortunately,  virtually  any  piece  of  software  documentation  could  arguably  be 
construed  to  be  within  this  rule,  so  there  would  seem  to  be  within  the  regulation  yet  another 
potential  pitfall. 

Conclusion 

Given  this  complicated  and  ambiguous  regulatory  environment,  it  is  understandable  that  a 
software  firm  that  might  be  jealously  guarding  its  software  and  documentation  in  order  to  preserve 
its  competitive  edge  in  the  marketplace  might  be  somewhat  reluctant  to  do  business  with  the 
Defense  Department.  It  is  a  system  in  which  the  Defense  Department’s  contracting  personnel 
have  their  hands  tied.  Short  of  getting  permission  to  grant  a  deviation,  it  would  appear  that 
contract  officers  have  no  authorization  to  make  deals  that  go  against  clear  provisions  of  the 
standard  data  rights  clause. 

The  fact  that  a  contract  officer  would  even  consider  entering  into  special  agreements  as  well  as 
honoring  them,  despite  a  lack  of  authority  to  do  so,  serves  as  a  testament  to  the  goodwill  and 
reasonableness  of  the  many  DoD  personnel  who  want  the  government  to  get  good  technology, 
and  who  realize  that  if  the  standard  data  rights  policy  is  always  insisted  upon  and  enforced,  a  lot 
of  excellent  software  technology  will  not  be  made  available  to  the  government.  It  is  unfortunate 
that  the  Defense  Department’s  procurement  regulations  make  the  job  so  difficult  for  them,  and  at 
the  same  time,  put  at  risk  software  firms  who  want  to  believe  that  the  government  can  accom¬ 
modate  their  needs  for  protection  of  software,  and  who  want  to  make  their  technology  available  to 
the  government  on  fair  and  reasonable  terms. 

Why  are  the  Defense  Department  regulations  so  difficult  to  change?  Well,  that,  as  they  say,  is 
another  story.  Until  the  regulations  are  altered  to  accomodate  the  needs  and  interests  of  those  in 
DoD  who  want  access  to  the  highest  quality  software  technology  and  of  those  who  can  supply  it, 
software  vendors  must  be  prepared  to  journey  through  a  complex  and  sometimes  frustrating 
regulatory  maze. 
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